Should we also update CLIRequest::parseCommand() to handle the -- separator the same way? Right now it still uses the old logic, so service('request')->getOptions() will treat --flag after -- as an option.

Should we also update CLIRequest::parseCommand() to handle the -- separator the same way? Right now it still uses the old logic, so service('request')->getOptions() will treat --flag after -- as an option.

Okay, I can do that. But that would also mean we would have two places doing exactly the same thing. I'm thinking to update CLIRequest and have CLI call it. What do you think?

Okay, I can do that. But that would also mean we would have two places doing exactly the same thing. I'm thinking to update CLIRequest and have CLI call it. What do you think?

Hmm... I agree we should avoid duplicating the parsing logic, but I'm not sure having CLI call CLIRequest is the best direction. CLI is the smaller utility, while CLIRequest is a heavier request object, so that dependency feels a bit backwards. I think it would be cleaner to extract the parsing into a small shared helper and let both CLI and CLIRequest use it.

Hmm... I agree we should avoid duplicating the parsing logic, but I'm not sure having CLI call CLIRequest is the best direction. CLI is the smaller utility, while CLIRequest is a heavier request object, so that dependency feels a bit backwards. I think it would be cleaner to extract the parsing into a small shared helper and let both CLI and CLIRequest use it.

I was previously thinking CLIRequest to call CLI but realized CLI is static so any changes to it will be persisted. Ok, I will go with a helper.